---
title: 事件风暴
description: 使用事件风暴来进一步梳理需求，完成捕获行为需求。
---
根据 DDD 的基本开发流程，首先需要使用事件风暴方法来进一步梳理需求。

在真实项目中，尤其是敏捷项目里，领域专家很可能不会一开始就把需求都一一列出来，需求可能仅仅停留在领域专家的脑子里。所以，我们就需要一种方法，能够将这些头脑中的需求挖掘出来。

而且，即便领域专家已经把需求写出来，我们也很难保证没有遗漏，保证开发人员都彻底理解了。而事件风暴不仅能<RedSpan>帮助我们尽量把需求补充完全</RedSpan>，而且还能<RedSpan>以协作的方式保证业务人员和技术人员对需求理解一致</RedSpan>。

此外，事件风暴方法也能够帮助我们<RedSpan>识别领域对象</RedSpan>，这也是我们进行领域建模前的重要一步。尽管对于建模高手来说，通过“聊天”的方式就能把模型画出来，但对于多数开发团队而言，还是需要一种套路化的方法作为辅助，一步一步地做。


## 事件风暴的来源

一般来说，为了理解需求，我们首先要<RedSpan>分析系统具有哪些功能，这些功能由什么人操作，会产生什么效果</RedSpan>。这个过程传统上叫做“捕获行为需求”。

捕获行为需求的方法有好几种，在传统的软件工程中，最常用的方法是“用例”，也就是 Use Case。但是，Eric Evans 在《领域驱动设计》这本书里，并没有规定捕获行为需求的具体方法。直到 2013 年，一位叫 Alberto 的 DDD 专家提出了“事件风暴”，也就是 Event Storming。

这种方法简单易学，而且充分体现了 DDD 中沟通协作、统一语言等要点，所以逐渐开始流行起来。你可以先看看这张图，这里说明了事件风暴的主要过程：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130160422.png"/>

这里的第一步是识别领域事件，在这一步，我们要找到业务流程中发生了哪些事情；

第二步是识别命令，进一步说明是什么角色，做了什么操作，导致上述事情的发生；

第三步是识别领域名词，从领域事件和命令中找到名词性概念，为进一步的领域建模打下基础。


那么现在，就来想象一下如何在真实的项目中一起做事件风暴。

由于事件风暴是一个动态的协作过程，不太容易通过文字表达，所以在看后面内容的时候，你一定要充分发挥想象力，让头脑中有“画面感”，脑补出咱们两个人唇枪舌剑，反复讨论的过程。

## 事件风暴的准备

首先是人员的准备。事件风暴要求业务和技术人员共同协作。业务人员，也就是之前说过的“领域专家”，在实践中一般由业务部门的专家，或者产品经理、PO（Product Owner）、BA（Business Analyst）等角色来担任。技术人员呢，首先要有架构师，其次也可以有技术经理，或者其他的开发人员、测试人员也可以参加。

第二是场地准备。我们需要找一个比较大的会议室，或者至少有一面足够长的墙。

最后是器材准备。我们需要几套彩色的便利贴，到时候我们会把事件风暴的主要内容写在上面。另外，通常还要一卷一开的大白纸，把这些白纸打横，一字排开，贴在会议室的墙上，用来贴便利贴。

## 识别领域事件
好，现在还是我来扮演产品经理，你来扮演架构师。而且假设我以前做过事件风暴，而你是第一次，所以我比你知道得多一点。


一开始，我先口头给你讲了一遍需求，你大概听懂了。然后我们就开始事件风暴的第一步：识别领域事件。


所谓领域事件，就是在业务过程中，业务人员要关注的那些<RedSpan>已经发生的事</RedSpan>。比方说，对于电子商务系统，订单已提交、商品已签收等等，都是领域事件。实际上，领域事件表示的是，<RedSpan>业务流程中每个步骤引发的结果</RedSpan>。事件风暴的作者认为，从结果入手来梳理需求，比从操作入手，更容易把业务想清楚。事件风暴中的“事件”两个字就来源于领域事件。

另外，咱们还要注意领域事件的命名，如果套用英语的语法来说，一般是完成时 + 被动语态。比如说，订单已提交，这个“已”字就是完成时，代表已经发生的事情。而订单已提交也可以说成订单已“被”提交，实际是被动语态，只不过一般把被字给省掉了。

### 识别项目管理流程的领域事件

接下来咱们一个一个业务流程来做。至于具体先做哪个流程，并没有特别的规定。不过由于项目管理这个流程比较长，我们就拿这个流程为例来讲吧。

首先，咱们花十来分钟时间，各自按照自己的理解，把项目管理中发生的各个领域事件，分别写在橙色便利贴上。然后按大致的时间顺序贴在墙上。每人贴一行。写出来以后大概是下面这个样子：


<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130160645.png"/>

然后，就可以对比咱们两个人写得有什么不一样，再经过讨论得出一致的结果。现在，咱们从左到右看一下。

第一步就发现了一个小区别。你写的是“客户已创建”，我写的是“客户已添加”

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130160839.png"/>

那么你就会问我：“业务人员一般会说客户已创建还是客户已添加呢？”

我告诉你：“一般是说客户已添加，因为从业务的角度，客户本来就是存在的 ，不需要创建，只是把客户资料添加到我们的系统而已”。你表示同意。

然后我又叮嘱了一下：“以后添加客户的时候，都说添加这个词，别再说创建了。”这时候，其实我们已经是在建立“统一语言”了。统一后的结果是下面这个样子：


<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130160858.png"/>

第二步，你写的是“签订合同”，我写的是“合同已签订”。

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130160919.png"/>

一说你马上就反应过来了，刚才我们说过要用完成时和被动语态，“签订合同”是个动作，不是事件。所以达成一致后，结果变成下面这样：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130160935.png"/>

下一步，你写的是“项目已创建”，我写的是“合同已生效”。不过我后面还有一步“立项”，应该和你的“项目已创建”是一回事，所以说明我比你多了一步“合同已生效”。

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130160953.png"/>

于是你又问了：“合同签订以后不是马上就生效了吗，还要有一个额外的生效步骤吗？”

我解释说：“合同签订的时候未必马上生效，比如 1 月 1 日签了合同，但合同中可以约定，真正生效是在 2 月 1 日，所以需要一个单独的步骤让合同生效。”这时候，你知道了一条原来不知道的领域知识。

然后你又问了：“我写了项目已创建，但是你写的是已立项，你这种写法好像和其他的不太一致呀。”

我解释说：“虽然我们为领域事件命名的时候，常常用‘什么什么已什么什么’的形式，不过如果业务上已经有约定俗成的术语，我们就直接使用术语，这样更容易和业务沟通。现在业务觉得已立项是一个通用的术语，写成项目已创建反而显得生硬。”

现在你又知道了，<RedSpan>在 DDD 中的各种命名，一般都优先使用约定俗成的业务术语。统一后的样子如下图</RedSpan>：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130161149.png"/>

不过我在“项目已结束”前面还多了一个“员工已分配”。

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130161207.png"/>

于是你又问我：“刚才你讲需求的时候，好像是把**员工分配**作为一块单独的需求来讲的，不属于**项目管理**这个流程吧？”

我想了想，说：“员工分配背后的业务逻辑有点复杂，所以之前单独拿出来讲，其实员工分配是项目运作中的一个重要环节，放在项目管理中也没毛病。”你对此表示认可。


这时我又补充了一点：“员工分配到项目的时候，要填入预计的投入工作量的百分比，一个人可以同时上多个项目，但预计的投入百分比总和不能超过 100%。这种逻辑一般叫**业务规则**，为了避免忘记，咱们也写在便利贴上吧。”


于是我们把业务规则写在浅灰色便利贴上，贴在“员工已分配”事件的下方。经过这几步，结果变成了下面这个样子：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130161318.png"/>

再下一步，你多了一个“客户已终止”

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130161333.png"/>

我解释说：“客户可以在系统中长期存在，以便不断挖掘商机，一般不必专门进行终止。理论上说，万一客户破产了，是应该终止，不过目前业务上还没有这个需求，这一点可以以后再考虑。”于是我们把“客户已终止”拿掉了。

然后你又发现，我的流程中最后还多了一个“客户经理已更换”。

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130161411.png"/>

你有点惊讶地问：“可以更换客户经理吗？你刚才好像没说呀。”

我说：“可以更换，我刚才忘记说了。

你紧跟着追问：“那么负责合同的销售人员，还有项目经理是不是也可以换呢？”

我说：“也可以，我自己都忘了写了。”

于是我们补充了这几个事件。同时，由于这三个领域事件不一定会出现，所以我们决定另起一行，也就是第一行表示主流程，包括必然发生的事件，第二行表示可选的事件。现在统一后，就变成了下面这个样子：


<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130161451.png"/>

最后，我们把整个流程又仔细检查了一遍。你眼尖，又发现了一个遗漏的领域事件。员工分配到项目上以后，还可以退出项目，所以应该有一个“员工已退出”事件。


好补充以后，最终结果就是下面这个样子：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130161525.png"/>

现在，我们终于为项目管理流程，完成了“识别领域事件”这个步骤。
### 识别其他流程的领域事件
用同样的方法，可以识别其他流程的领域事件，这里就不一一重复了。下面这张图是我们识别出的所有领域事件：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130161657.png"/>

在这张图里，你可以看到，有些业务规则在最开始的需求描述里是没有说明的，而是在咱们不断地讨论中，逐步澄清的。此外，我们还用橘红色的便利贴表示业务流程的名字，以便区分。


关于领域事件，我们还要注意下面这两点。

第一，<RedSpan>不要把技术事件当成领域事件</RedSpan>。领域事件一定要是领域专家所关注的，用的是业务术语。像数据库事务已回滚、缓存已命中之类的技术术语，不是领域事件，不在这个阶段讨论。

第二，<RedSpan>查询功能不算领域事件</RedSpan>。领域事件应该是对某样事物产生了影响，并被记录的事情。一般是某个事物的创建、修改和删除。还有一种情况是向其他人或者系统发消息，例如“通知邮件已发送”也算领域事件，因为接收方可能会通过进一步处理来影响某些事物。

而像“客户信息已查询”这些就不算领域事件，因为还没有对事物产生实际影响。不过，这并不代表查询功能不重要，查询功能也要以某种方式体现。这一点在后续的课程我们再讲。

到这里，我们就完成了事件风暴的第一步“识别领域事件”，后面两步“识别命令”和识别“领域名词”将在下一节课讲解。

## 识别命令
现在，开始事件风暴第二步，识别命令。

<RedSpan>所谓命令（command），就是引发领域事件的操作</RedSpan>，可以通过分析领域事件得到。除了识别出命令本身以外，通常还要识别出谁执行的命令，以及为了执行命令我们要查询出什么数据。

比如说，对于“合同已签订”这个事件，对应的命令就是“签订合同”。这里，我们在水蓝色的便利贴上写出命令，然后贴在对应的领域事件上方。如下图：


<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130173150.png"/>

那么“签订合同”这个操作是什么人执行的呢？需求里说是“销售人员”。这里的销售人员术语上叫做“执行者”，英文是 actor。我们把执行者写在小一点的粉色便利贴上，贴在命令上方，如下图：


<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130173218.png"/>


为了表示执行者是人，这里还在便利贴上画了一个小人儿。之所以这样，是因为有时执行者还可以是系统，可以在便利贴上画一个屏幕的图像表示系统执行者。像下图这样：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130173246.png"/>

这里还有一个问题，在执行“签订合同”操作时，执行者要先从系统里查出客户信息，才能和这个客户签订合同。这里，“客户”是一种“查询数据”。我们把查询数据写在小一点的绿色便利贴上，也贴在命令上方，如下图：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130173317.png"/>

这样，一个命令的所有信息就识别完了。现在，假设我们按照前面的方法一边讨论，一边识别出所有的命令，结果就是后面这个样子。


<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130173354.png"/>

关于这个图，我们还要再补充说明几点。

首先，有些命令可能没有查询数据。比如添加客户，从需求来看，添加客户时不需要查询出什么其他信息，如下图：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130174155.png"/>

其次，还有的命令会有多个查询数据。比如说为项目分配员工，要查出项目和员工两个信息，如下图：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130174259.png"/>

另外，还有的命令会有多个执行者。例如更换客户经理，既可以由客户经理把自己的客户转给另一个客户经理，也可以由客户经理的上级来操作，这时就可以有不止一个执行者了，如下图：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130174808.png"/>

看到这里，你可能会提出疑问：“客户经理上级”这个执行者含义好像有些模糊呀？比如说，客户经理的上级还是客户经理吗？对于这个问题，我表示一时也没想清楚，可以先这么写，留到进一步做领域建模时再澄清。

还有最后一点你要注意，执行者是某个角色，而不是具体的人。例如“张大文”是一个客户经理，这时在便利贴上写的是“客户经理”这个角色，而不能是张大文这个具体的人。

## 识别领域名词
识别完命令，我们来做第三步，识别领域名词。

这里说的领域名词，是从命令、领域事件、执行者、查询数据里找到的名词性概念。例如，对于签订合同这个命令而言，受到影响的名词性概念是“合同”；类似地，对于合同已签订这个领域事件，是由于“合同”这个名词性概念的状态变化所导致的。


识别领域名词的操作步骤可以分成两小步。

第一步，我们要挪动上一步的便利贴，把围绕同一个名词的命令、事件、执行者、查询数据摆在一起，分成好几“堆”，贴在墙上。下图是其中一部分：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130175852.png"/>

第二步，把领域名词写在大一点的黄色便利贴上，贴在每堆便利贴的中间，如下图：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130180154.png"/>

所有领域名词都识别出来后，就是下面这个样子：

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130180233.png"/>
<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130180244.png"/>

让咱们再仔细看看这张图。

首先我们发现，“为项目分配员工”和“员工已分配”出现了两次，一次是关于“员工”的，另一次是关于“项目”的。

因为这对命令和事件是关于两个名词的，所以我们抄写了两遍。其中你可以看到，关于项目的那次，我在命令和事件后面加了一个 “2” ，就是同一个概念在图中出现了第二次的意思，这是我们画图时的一个常用技巧，其他有 “2” 的命令和事件也是同理。

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130190252.png"/>

另外，我们还看到，“企业”这个名词只和“企业”这个查询数据有关，但是没有“添加企业”之类的命令。


咱们俩讨论了一下，认为租户和企业是一回事，添加了租户，自然就添加了企业，所以目前这样好像没毛病。那就先这样吧，如果还有问题的话，等到领域建模的时候再澄清。

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130190312.png"/>

类似地，管理人员和人事人员也只和执行者相关，而没有相应的命令。这些我们都可以留到领域建模的时候再进一步想清楚。

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130190328.png"/>

现在，我们就完成了事件风暴的所有步骤，后面就可以用这个为基础进行领域建模了。

## 再谈事件风暴的作用
在进行后续的工作之前，咱们还是来归纳一下事件风暴的作用，进一步加深理解。

上面我们已经说过，事件风暴是业务人员和技术人员一起协作，捕获行为需求、消化领域知识、形成统一语言的一种方法。这是就整体来说的。

首先我们看看领域事件的作用。从代码实现的角度来看，领域事件一般会对应一段代码逻辑，这段逻辑可能会最终改变数据库中的数据。另外，在事件驱动的架构中，一个领域事件可能会表现为一个向外部发送的异步消息。

那命令的作用体现在哪儿呢？领域建模时，我们可以通过对命令的走查（walkthrough），细化和验证领域模型。在实现层面，一个命令可能对应前端的一个操作，例如按下按钮；对于后端而言，一个命令可能对应一个 API。

再来说命令的执行者。在领域建模时，执行者可能本身就是一个领域对象，也可能是领域对象充当的角色，或者是权限管理中的一个角色。

至于查询数据，我们上一讲说过，查询功能不产生领域事件，因此也不会有相应的命令。那么怎样保证查询功能不被遗漏呢？

实际上，每个查询数据，就对应着一个查询功能。不过，这里的查询数据是为了某个命令服务的。系统中可能还有一些单纯的查询功能，并不与某个特定的命令绑定。这些查询功能不会通过事件风暴识别出来，需要单独进行分析。

最后，我们再看看领域名词的作用。其实识别领域名词的最终目的是要找到领域模型中的对象。那么为什么我们不把这一步直接叫做识别领域对象呢？

这是因为，在这一步里识别出的名词，虽然很可能就是领域对象，但也未必。一个名词有可能只是一个对象充当的角色，或者对象的属性，还有些名词需要经过合并或拆解后，才是合理的领域对象，而这些需要等到领域建模时才能真正搞清楚。

事件风暴本身并不是进行这种深入分析的合适工具，所以，我们在这一步只需要识别出领域名词就可以了，这些名词将成为领域建模的“素材”。


## 事件风暴常见问题
#### Q1: 在事件风暴里是否要列出所有的领域事件和命令？
<RedSpan>在事件风暴里只列出主要的、足以用于表达和交流领域知识的步骤</RedSpan>，例如签订合同、生效合同等等。而像修改合同和删除合同这样的步骤是显而易见的，在讨论过程中可以提一下，但不必真的列出来，这样是为了保持简洁。

那么不列出来，怎么保证这些功能不被遗漏呢？我们可以结合用户故事或者传统的功能列表等方法保存系统功能的全集，这样就能解决了。

#### Q2: 各个领域事件需要体现严格的时间顺序吗？
应该关注点分离。如果要体现严格的时间顺序，我们可以用流程图、用顺序图等方法，但事件风暴不必关注这一点。

#### Q3: 每个步骤的颗粒度应该有多大？
这里说的步骤，指的是一对领域事件和命令。

比如说，“签订合同”这个命令，在具体操作的时候，可能分成录入合同基本信息、录入合同明细、上传附件等等更小的步骤。那么，我们需要为每一个小步骤都识别出领域事件和命令吗？

这就要考虑从业务的角度，我们是把每个小步骤都当作独立的一个事务来看待，还是把它们合起来作为同一个事务。

另外，可以设想，如果每个小步骤都向外界发出一个领域事件，对系统后续的功能是不是有意义。那么在目前的需求里，合同作为一个整体来提交就可以了，分成小的领域事件，并没有意义，所以不再分成更小的步骤了。

在实践里，有时仍然会有模棱两可的情况，这时，原则上宜粗不宜细。可以先采用比较大的颗粒度。后面必要的时候，再拆细，就可以了。

#### Q4: 事件风暴适用于所有项目吗？

这个问题可以从两个层面回答。第一个层面，事件风暴主要应用在需求不清晰，或者理解不统一的情况下，通过协作的方式理清业务、达成一致，所以通常对于新项目比较适用。

至于遗留系统改造的情况，如果这个系统的知识已经流失得很严重，那么事件风暴仍然是有意义的。但如果大家对这个系统的业务知识很清楚，只是要进行架构改造，那么事件风暴的意义就不大了。


第二个层面，即便在适用的场合，事件风暴也不是唯一的方法，我们还可以用用例分析、用户故事等方法实现类似的目的。只要抓住协作、统一语言等等要点，这些方法都可以用在 DDD 的项目里。

所以，如果你的项目里还没有正规的、令人满意的捕获行为需求方法，那就可以使用事件风暴。如果已经有了成熟的方法，你可以借鉴事件风暴的思路，在原来的方法里加入协作、统一语言、识别领域名词的实践，也能达到同样的效果。


#### Q5: 怎么保存和维护事件风暴的结果？

到现在为止，事件风暴的结果都是贴在便利贴上的，显然不容易长期保存。一般来说，我们可以在事件风暴的过程中专门安排一个记录员，由他使用 PPT 之类的画图工具，把贴在纸上的内容重新画一遍，就可以实现电子化的保存了。

还有一个更深入的问题是，事件风暴是不是需要长期维护和更新？还是说我们只是把事件风暴当作一次性的步骤，不必长期维护？

通常，如果事件风暴的内容最终会反映到用户故事、用例、功能列表等产出物中，而这些产出物会进行维护，那我们就不必专门更新事件风暴的产出物了，只在需要的时候作为一种沟通工具，将电子化的结果作为一种中间产物保存就可以了。

但是，如果你的团队并没有用户故事和用例等保存行为需求的方式，那么我建议你对事件风暴进行维护和更新。

除了绘图之外，事件风暴也可以用表格的形式来保存，你可以参考一下后面的表格。

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130233817.png"/>

不过，这个表里的领域对象需要在领域建模阶段才能分析清楚，这里先空着，到时再回填。

#### Q6: 怎么保存领域规则？

领域规则是重要的领域知识，必须妥善保存。在事件风暴的过程里我们已经识别出了一些领域规则，在后续的领域建模阶段，可能还会识别出更多。如果只是写在便利贴上，或者画在图上，时间长了，就很难维护了。

所以，我们要编一个领域规则表，把所有的领域规则都汇总在里面，然后再把领域规则表和领域模型放在一起，作为领域知识的重要组成部分，后面就是一个例子。

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241130233925.png"/>





## 总结

事件风暴是一种通过协作的方式捕获行为需求的方法，在这个过程里，业务人员和技术人员一起消化领域知识、形成统一语言、并为领域建模奠定基础。

事件风暴分为识别领域事件、识别命令、识别领域名词三个步骤


事件风暴是从识别领域事件开始的。“领域事件”是在业务过程中，业务人员关注的那些已经发生的事情。技术事件和查询功能都不算领域事件。领域事件意味着业务流程中每个步骤的结果。这种结果导向的思维方式更容易理清业务。事件风暴中的“事件”两个字就来源于领域事件。

识别领域事件的过程可以分成了两大步：第一步是参加的人，各自写出领域事件；第二步是一起讨论，统一理解。这种先发散，后收敛，反复迭代的过程实际上就是一种头脑风暴。


头脑风暴是一种常见的协作方式，可以让一群人一起通过思维的碰撞，分析问题，最终达成一致。事件风暴中“风暴”两个字就来源于“头脑风暴”。

在这个过程里，我们已经开始形成 <RedSpan>统一语言</RedSpan>。所谓统一语言，英文是 <RedSpan>Ubiquitous Language</RedSpan>，是 DDD 中的一个核心模式。指的是业务人员和开发人员使用的语言要一致。语言是知识的载体。语言一致就意味着背后对领域知识的理解一致。统一语言贯穿了 DDD 的全过程。

同时，也开始识别业务规则。

一定要注意，<RedSpan>“协作”才是事件风暴的精髓</RedSpan>，而具体结果怎样呈现，反而是第二位的。

命令”是引发领域事件的操作，可以从领域事件“反推”出来。此外，还可以识别命令的两个附加信息，一个是发出命令的“执行者”，另一个是为了完成命令要查询出的数据。


“领域名词”是隐含在命令和领域事件中的名词性概念。这些名词是领域建模的素材, 而对于这些素材的深入分析可以留到领域建模进行。




